pybricks/bluetooth: Add bt classic inquiry scans. #432
Conversation
jaguilar
force-pushed
the
ev3-bluetooth-scan
branch
from
e022c4b to
5bb845e
Compare
jaguilar
force-pushed
the
ev3-bluetooth-scan
branch
from
de407e3 to
cb7bfec
Compare
|
Rebased this commit atop all the other refactoring work that has happened recently to btstack, and verified that everything is still working. |
The ev3 can now scan for discoverable Bluetooth devices.
jaguilar
force-pushed
the
ev3-bluetooth-scan
branch
from
cb7bfec to
ebf3c1e
Compare
|
Thanks for submitting this! I can confirm that this is giving scan results. After working on Bluetooth/BLE for the past couple of weeks, I have a few ideas on how we might integrate this into the Bluetooth driver. I'll post an alternate draft PR soon. Hope that's OK. My goal isn't to rewrite all PRs. Once we've established a good pattern I think we can extend it quite easily to other functionality. I think we can do this without the manual memory management done here (multiple root pointers, and manual control of MicroPython is able to do most of this for us. We can instead use In #445, I've been working on making Bluetooth tasks chronological. I think the scanner lends itself well to this pattern too: pbio_error_t pbdrv_bluetooth_inquiry_scan_func(pbio_os_state_t *state, void *context) {
PBIO_OS_ASYNC_BEGIN(state);
gap_inquiry_start(duration);
// Wait until the number of devices are found or scan timeout
PBIO_OS_AWAIT_UNTIL(state, count == count_max || ({
if (hci_event_is_type(event_packet, GAP_EVENT_INQUIRY_RESULT)) {
// process a single result contained in event_packet here
// no callbacks needed, just store it in the context provided array of results
}
// The wait until condition: inquiry complete.
hci_event_is_type(event_packet, GAP_EVENT_INQUIRY_COMPLETE);
}));
PBIO_OS_ASYNC_END(PBIO_SUCCESS);
}This is also nicely extensible if we make a scan-and-connect task later. We'll also need to make these tasks cancellable. So that we stop scanning when the program ends or the user interrupts this action. With this pattern, we can do that relatively easily. I think we're also going to need some kind of Bluetooth loop that can queue/refuse multiple Bluetooth calls, just like we have with BLE. It wouldn't be safe to have two scans running, for example. The current BLE loop is something like this: I haven't quite decided if our Bluetooth classic loop should be entirely parallel or just add to the existing loop like: I'm leaning towards managing it in the same loop, so we can keep ensuring that Bluetooth activity is somewhat sequential. Running them in parallel could save a little bit of time if the user was doing something with BLE and classic at the same time, but this doesn't seem worth the extra complexity. |
|
Sounds good. If you are intending to rewrite the PR, I will just wait until that happens. Once it's done, I'll adjust the following PR to have the same format, hopefully. Not sure if it will be possible to follow exactly but we'll see. |
|
It's mostly done, but it needs some polishing like adding cancellation. |
|
OK, here is a draft before calling it a day. The last Basic testing done on Virtual Hub and EV3 (both Bluetooth chipsets). For Virtual Hub, there's a ready made vscode launch config ( |
3 participants
Any Pybricks device running btstack can now issue Bluetooth classic inquiry scans to find and report discoverable devices.
This API is experimental and we can change it later if we don't like it. But it's nice because it can be used to concretely demonstrate that the EV3's BTStack layer is doing something! This also should give some indication of the structure by which we'll add further classic functionality (more functions and switch entries in
bluetooth_btstack_classic.c). If it's preferred to have it in the same file as the LE code, we can, but this structure is scarcely more expensive and a little more neatly organized.You can test it with this program: